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Situation calculus has been widely applied in Artificial Intelligence related fields. This formalism is 
considered as a dialect of logic programming language and mostly used in dynamic domain model- 
ing. However, type systems are hardly deployed in situation calculus in the literature. To achieve a 
correct and sound typed program written in situation calculus, adding typing elements into the current 
situation calculus will be quite helpful. In this paper, we propose to add more typing mechanisms 
to the current version of situation calculus, especially for three basic elements in situation calculus: 
situations, actions and objects, and then perform rigid type checking for existing situation calculus 
programs to find out the well-typed and ill-typed ones. In this way, type correctness and soundness 
in situation calculus programs can be guaranteed by type checking based on our type system. This 
modified version of a lightweight situation calculus is proved to be a robust and well-typed system. 

1 Introduction 

Introduced by John McCarthy in 1963 [10], situation calculus has been widely applied in Artificial 
Intelligence related research areas and other fields. This formalism is considered as a dialect of logic 
programming language and mostly used in dynamic domain modeling. Based on First Order Logic 
(FOL) [1 ] and Basic Action Theory [9 ], situation calculus can be used for reasoning efficiently by virtue 
of dynamic elements, such as actions and fluents. Basic concepts of situation calculus are fundamentals 
of First Order Logic and Set Theory in Mathematical Logic, which greatly facilitate the process of 
action-based reasoning in situation calculus. 

In order to make programs sound and correct in semantics, people have proposed type systems [12J to 
ensure such significant properties. A well-typed programming language is determined by two semantic 
properties: preservation and progress. The first property makes sure that types are invariant under the 
evaluation and typing rules. And the progress property says a well-typed program never gets stuck. 
Nevertheless, little attention has been put on equipping formal languages good at dynamic modeling 
and reasoning, like situation calculus, with strong typing mechanisms. Indeed, situation Calculus is a 
typed second-order formal language, but from the viewpoint of type checking, it is not enough to finish 
smoothly. For instance, in situation calculus, only typed quantifiers are introduced for basic variables, 
while as for other logical expressions consisting of variables and connectives, fluents and predicates, 
current situation calculus emphasizes little on how to type check whether they are well-typed, how to 
type them thoroughly. Therefore, equipping other elements in current version of situation calculus with 
types is greatly needed for a complete and robust programming language with its type system, which is 
definitely feasible according to our investigation. 

In this paper, in addition to the handy available typed variables, we propose to add more typing 
mechanisms to three basic elements in situation calculus: situations, actions and objects, consider a 
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classical scenario for a piece of program based on the modified lightweight situation calculus, and then 
perform rigid type checking for the situation calculus program. If type errors are found, we would provide 
corresponding recommendation on how to correct the program into a well-typed one. Furthermore, to 
support our ideas in practice, we implement a type checker to semi-automatically finish the type checking 
work instead of working manually. 

We organize our paper in the following way: section 2 introduces the related work on typing situation 
calculus and its variants; Section 3 presents the basic ideas on type systems and situation calculus in a 
straightforward way; Section 4 illustrates the primary ideas on how to type a lightweight core of the 
original situation calculus; Section 5 evaluates our typing mechanisms by type checking an existing 
piece of program in situation calculus and section 6 concludes this paper. 

2 Related Work 

Due to its powerful action-based reasoning ability, situation calculus is often chosen as the formalism 
to express other models and programming languages which are either too complex to understand and 
use, like Artificial Intelligence in games [5] and Planning Domain Definition Language (PDDL) (6J, or 
a little powerless to represent an entire complicated systems of different types, like Action Description 
Language (ADL) ifTTTl . In the literature employing situation calculus as a formal method to express the 
semantics in PDDL [3 ] and ADL [4], the authors have tried to introduce some typing mechanisms, which 
is only limited to add type element in syntax, and only applied to variables. Other significant terms, such 
as fluents and predicates, are still typeless. Moreover, in semantics and reasoning, typing mechanisms 
are hardly discussed in these papers, neither is type checking. 

Yilan Gu et al. [7] proposed a modified version of the situation calculus built using a two-variable 
fragment of the first-order logic extended with counting quantifiers. By introducing several additional 
groups of axiom to capture taxonomic reasoning and using similar regression operator in Raymond 
Reiter's work [13], the projection and executability problems are proved decidable although an initial 
knowledge base is incomplete and open. While their system concerns primarily on semantics of the new 
components proposed but rarely talks about typing on them, our well-typed version of situation calculus 
mentions typing mechanisms together with a modified situation calculus version in an all around way. 

There are also some attempts on modifying situation calculus only based on a lightweight version of 
the original one. Gerhard Lakemeyer et al. ||U proposed a new logic dialect of situation calculus with the 
situation terms suppressed, namely, £S. That is, it is merely a similar formalism as a part of the current 
situation calculus. Moreover, in this paper, the authors consider how to map sentences between £ S and 
situation calculus and try to prove £S is powerful enough to handle most cases as the situation calculus 
does, but mention little about how to type their new logic system as a fragment of situation calculus. 

3 Background Knowledge 

3.1 Type Systems 

In the discipline of computer science, modern type systems are regarded as a formal mechanism origi- 
nated from Alonzo Church's X calculus proposed in 1940 flU. One possible definition of a type system is 
"a tractable syntactic framework for classifying phrases according to the kinds of values they compute" 
lfl2l . By associating types with each computed value, a compiler can detect meaningless or invalid code 
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written in a given programming language. For instance, the expression "mix = 29 + "Tan"" cannot get 
through type checking since a string cannot be added to a number. 

There are many branches in type systems, such as inferred typing and manifest typing (implicit and 
explicit), and strong typing and weak typing. As for type checking, people can utilize dynamic type 
checking and static type checking, or a combination of both. 

The primary and most obvious purpose of using type systems is to guarantee the correctness of 
programs, i.e., detect potential errors, while a well-typed system can further ensure the soundness (safety) 
of programs. The most important characteristics of a well-typed system are properties of preservation 
and progress. The former one makes sure a term can keep its type passed into the term that it is evaluated 
to, and the latter keeps reachability of a term: a typed term can either turn into a value or another related 
term, which means a well-typed term will not get stuck. In this paper, we plan to equip the current 
version of situation calculus with appropriate type system besides several original ones for variables. 
Thus, a program written in situation calculus can be easily type checked correct or not. 

3.2 Situation Calculus 

Situation Calculus [ 10] is a formal method based on First Order Logic and Set Theory in Mathematical 
Logic, with a strong ability of action-based reasoning. This formalism is considered as a dialect of logic 
programming language and mostly used in dynamic domain modeling. In situation calculus, the world 
is comprised of situations, actions and objects. The semantics of these three key components in situation 
calculus is given informally below. 

A situation represents a possible world history, simply a sequence of actions, denoted by a first-order 
term. The constant so is used to denote the initial situation, namely, the empty sequence of actions. 

An action represents any possible change to the world, denoted by a function, for example, drop(A), 
clean(B) and check Jn(ID). 

An object represents an entity defined in the domain of a specific application, denoted by a first-order 
term, for example, x, robot Jl and table. 

Moreover, other than aforementioned three elements, there is another significant symbol used fre- 
quently in situation calculus, namely, fluents. A fluent represents a relation or a function whose truth 
values varies from one situation to the next, called relational fluent or functional fluent respectively. 

Additionally, introduce two predefined binary symbols of fluents as follows: 

Function symbol do is defined as do: Action x Situation — > Situation, which maps an action a and 
a situation s to a new situation called successor situation, which results from performing the action a in 
the situation s. This successor situation is denoted as do(a, s). 

Predicate symbol Poss is defined as Poss: Action x Situation. Similarly as above, Poss(a, s) means 
it is possible to execute the action a in the situation s. Note that in the original situation calculus, there is 
no return value for Poss. For consistency, in our well-typed system, we assign a unit value for every Poss 
predicate. In other words, Poss is defined as Poss: Action x Situation — > Unit (Capital "U" indicates it 
is a type but not a value.). 

As mentioned before, fluents are used to represent a term whose value varies according to the chang- 
ing of situations. As a comparison, another symbol is defined to denote a term whose value does varies 
with situations, namely, predicate. For example, hunger _status(person, time) and weather _condition( location, 
season) are relational fluents while drop(person, object) is a predicate, since in the first two fluents, the 
second arguments are actually situations, namely in situation calculus, s, and in the third term there is 
no specific situation, but only two objects, which means the value of this term will not change when 
situation changes. 
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4 A Well-typed Mechanism in Situation Calculus 

4.1 A Lightweight Situation Calculus 

The situation calculus we study and try to extend here is a lightweight version of its original form. 
Similarly as Featherweight Java (FJ), we only grab some core features in situation calculus and skip 
derivable forms to keep our ideas concise and efficient. 

According to the language of situation calculus, we keep all the static domain element: situations, ac- 
tions and objects, and the majority of functional elements like fluents do and poss, and all the predicates. 
The components we ignore are those that either can derive from other elements or similarly be expressed 
by others. For instance, the ordering predicate C, which defines an ordering relation on situations, can 
be expressed implicitly by the return value of other fluents and predicates. Like the expression s' C s 
which denotes that s' is a proper subsequence of s, s' could be replaced with a fluent or predicate which 
leads s to s', say, do(findajob(person: Object, job:Object), s: Situation). 

Likewise, we replace countably infinitely many predicate symbols with arity n, (act ion U object) 11 
with t, which is a shorthand of a sequence of terms t\,t2, ■■■,t n (n > !)• 

4.2 Handy Typing Mechanism 

In the original situation calculus, several elements such as quantifiers are typed [13]. The handy typed 
elements are described formally as follows: 

A typed notion z(x) is used to denote x associated with a finite set of all possible types: 

def 

z(x) = x : T\ V x : T% V . . . Vx : T„, where Ti,Tz,...,T n are types of terms. 
Moreover, typed quantifiers are given by virtue of: 

(Vx : t)0(jc) = (Vx).t(x) D(j)(x), 

{3x:z)<j)(x) = (3x).z(x)A<j)(x). 

Thus, expressions that contain such typed quantifiers could be rewritten as sequences of conjunctions 
and disjunctions: 

(Vx : z)<j>(x) = <K7i) v<Hr 2 ) v . . . v0(r„), 

(3x : t)4>(*) = $ (7i) A <j>(T 2 ) A . . . A %). 

4.3 A New Type System in the Lightweight Situation Calculus 

Although the original version of situation calculus equips some components with corresponding types 
and semantics, it is not enough to do type checking based on these definitions. We proposed a new 
well-typed system to enable potential task of type checking in a convenient way. 

Syntactic Forms 



t ::= ... terms: 

x variable 

Vx universal quantified variable 

3x existential quantified variable 

-i? negative term 

t\ D ?2 subset logical connection 

t\ A £2 con junction logical connection 

t\ V?2 disjunction logical connection 
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Action 
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Semantics 

Given a world w comprised of situations, actions and objects and 
in w, if a term f holds in w, we write w |= f. Given a set of situations S - 



a set L(w) of all instances defined 
= {jo,Ji,---,Sn} (n>0),we have: 



w ^x 44> 

w |= Vx 44> 

w |= 3x o 

w |= -x 44> 

W |= D ?2 

W |= t\ A f 2 <^ 

w |= h V ?2 

w \=t O 

w \= -bt 44> 

w\=r(t,s) 44> 

w \= f{t) & 

w \=do(bt,s) <^ 

w \=poss(bt,s) <^ 

Evaluation Rules 



x G L(w) 
Vjj £ S,w\= x 
3si <E S,w\= x 
w^x 

W |= t\ => W \= t2 

w |= t\ and w |= t 2 

w |= t\ or w |= ?2 

w \=h,w \=t 2 ,...,w \=t n 

w^=bt 

w\=t and w \= s in r 
w |= t in f 

3sj £ S,bt holds in Sj 

3si £ S,w |= (jj Ddo(bt,Si)) 



(x)bt - 


->■ (^)if 


(Vx)bt - 


-5- (Vjc')fo 


(x)bt - 


-4 (x')to 


(3x)bt - 


-4 (Ebt')fcf 


t -> f' 




-if ^ - 


■f' ' -nfe -> 




^fj 


fl D f 2 fj 3 ?2 




-4fJ 


fl A f 2 


-> f J A f 2 


fl 


^fj 



fl V f 2 -> fj V f 2 



t -4- 1' 

E-Unv 
E-EST 

E-Neg 
E-Spt 

E-Conj 

E-Disj 



Li Tan 



67 



E-Seq 

E-Do 
E-POSS 
Wht: T 



hi t2, t n — > t[, t2, t n 

do(bt,s) ->[jh> s']bt 
poss(bt,s) — > s D [j i->- s']Z?f 
Typing Rules 

Here we continue to use W (rather than the lower case w used in semantics) instead of conventional 
r to denote a typing context. Formally, we have: 

W h frwe : Bool 

W h /o/jg : Bool 
x:T eW 




W\-t:T Whbf.T 



W \ : T ' f hnftcr 



Wh (Vie fi) x 


: 7i D (Vy e r 2 ) >' : ?2 


Wh (fj : 


?l) A (f 2 : r 2 ) 


Wh (Vx € fi) x 


: 2\ A (Vy e h) y : T 2 


Wh (t x : 


Ti) V (f 2 : r 2 ) 


Wh (Vx e fi) x 


: 7\ V (Vy et 2 )y: T 2 


( fl : 7\), (f 2 : r 2 ), % : T„) 



Wh (Vxefi)x: r b (Vzer„)z: r„ 

W h r : Ofc ject^tSituation-^Situation, t : Ob ject, s : Situation 
W h r(f, .s) : Situation 

W\- f : Ob ject^> Action Wht : Ob ject 
W h /(f) : Art/on 

W, fa : Action h ,s- : Situation 
W\~ do(bt, s) : Situation 

W, bt : Action h s : Situation 
W\- poss{bt, s) : Unit 



T-Neg 
T-Spt 
T-Conj 
T-Disj 
T-Seq 
T-RelFlt 
T-FunFlt 
T-Do 
T-Poss 
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Item 


Description 


E-Unv 


If one term t' occurred in a given behavioral term bt derives from another term t also 
in bt, then all such terms t' in bt are also derivable from all such terms t in bt. 


E-EST 


If one term t' occurred in a given behavioral term bt derives from another term t also 
in bt, then there exists such a term t' in bt that is derivable from such a term t in bt. 


E-Neg 


If one term/behavioral term t'lbt' derives from another term tlbt, then not t'/bt' also 
derives from not tlbt. 


E-Spt 


If one term t' derives from another term t, then this also holds in superset operation. 


E-Conj 


If one term t' derives from another term t, then this also holds in conjunction. 


E-Disj 


If one term t' derives from another term t, then this also holds in disjunction. 


E-Seq 


If one term t' derives from another term t, then this relationship holds if t' and t are 
in a sequence of terms, respectively. 


E-Do 


In a specific situation s, behavioral term bt gets executed means situation s transits to 
its successor situation s' while doing bt. 


E-POSS 


In a specific situation s, behavioral term bt is possible means current situation s is a 
superset of its successor situation s' . 


T-True 


As a Bool type value, true is within the typing map W. 


T-False 


As a Bool type value, false is within the typing map W. 


T-Var 


If a variable x with type T is within the typing map W, then x : T derives from W. 


T-Unv1 


If all relational fluents r that have an argument x with type T hold, then all occurrence 
of x in r must have a type T. 


T-EstI 


If there exists one relational fluent r that has an argument x with type T hold, then 
there must be one occurrence of x in r with a type T. 


T-Unv2 


If all functional fluents / that have an argument x with type T hold, then all occur- 
rence of x in r must have a type T. 


T-EST2 


If there exists one functional fluent / that has an argument x with type T hold, then 
there must be one occurrence of x in r with a type T. 


T-NEG 


If one term/behavioral term t'lbt' with a type T derives from the typing map W, then 
not t'lbt' also derives from W with the same type T. 


T-Spt 


If t\ with a type T\ as a superset of ?2 with a type T2 derives from the typing map 
W, then in W, all subterms x of t\ , y of t2 also have types T\ , T2 respectively, and 
superset relationship still holds. 


T-Conj 


If the conjunction of t\ with a type T\ and ti with a type T2 derives from the typing 
map W, then all subterms of t\, t2 also have types T\, T2, satisfying conjunction. 


T-Disj 


If the disjunction of t\ with a type T\ and ?2 with a type T2 derives from the typing 
map W, then all subterms of t\, t% also have types T\, T2, satisfying disjunction. 


T-Seq 


If a sequence of terms with its own types derives from the typing map W, then in W, 
all subterms of every term have the type their parent has. 


T-RelFlt 


Straightforward typing relationship of first-order logic. 


T-FunFlt 


Straightforward typing relationship of first-order logic. 


T-Do 


Straightforward typing relationship of first-order logic. 


T-POSS 


Straightforward typing relationship of first-order logic. 



Table 1 : A Directory of All Evaluation and Typing Rules in the Type System of the Lightweight 

Situation Calculus 
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Note: 

1. iisa shorthand of a sequence of terms f i , f 2 , • • • ,t„ (n > 1). Hence ? cannot possibly be empty. 

def 

2. The type Unit is defined as the type of value unit, where unit = {t\ (Vx G t) x : Bool V Situation V 
Action V Oft jec?}, which means all elements in a unit should have the same type. 

3. [s i->- in the computation rules E-Do and E-POSS means "the successor situation s' that results 
from executing the behavioral term bt in the situation s." See the items for E-Do and E-POSS in Table 1. 

4. The shadowed typing rules are adapted from the handy typing mechanism for quantifiers in current 
version of situation calculus, which is discussed in section 4.1. 

5. For simplicity, the detailed explanation is not given for typing rules T-RelFlt, T-FunFlt, T-Do 
and T-POSS. 



5 Evaluation 

5.1 Case Description 

Let us consider the following scenario: In face of an object x on the floor, say a vase, there is a robot 

r who wants to pick up this vase and paints it with some color, namely c. In situation calculus, we can 

describe this scenario using three statements: 

In a given situation s that, say, there is a robot r and a vase x ready for situations later on, if the robot 

r then picked up the vase x and dropped it without holding it firmly, which made the vase became broken, 

then the vase must be a fragile object: 

fragile(x,s) D broken(x,do(drop{r,x),s)) (1) 
If the robot successfully picked up the vase x and tried to paint it with one color c, holding it firmly, 

the vase would turn out to be in the color c: 

color{x,do(paint(x,c),s)) = c (2) 
Finally, let us consider the conditions on which it is possible for the robot r to pick up the vase x 

without any external help. The conditions should be a combination of three: the robot r is not holding 

any other object z, it is next to x, and x is not heavy: 

poss(pickup(r,x),s) D [(\/z)->holding(r,z,s)] A -^heavy(x) AnextTo(r,x, s) (3) 

5.2 Results and Analysis of Type Checking 

Now let us do the type checking on the aforementioned three statements that represent a scenario in 
which a robot r wants to pick up a vase x by itself and paints it with some fancy color c. On the basis of 
the type system defined in section 4.2, if all the typing goes through and does not get stuck, the program 
written in situation calculus will be regarded as well-typed. 

First, we need to add predefined types for programs written in the original situation calculus by virtue 
of our new type system. Hence we have: 

fragile(x : Ob ject, s : Situation) D broken(x : Object, do (drop(r : Ob ject,x : Object),s : Situation)) 

(iy 

color{x : Object,do(paint(x : Object, c : Object), s : Situation)) = c : Object (2)' 
poss(pickup{r : Ob ject,x : Ob ject),s : Situation) D [(Vz : Object)^holding(r : Ob ject,z '■ Object,s : 

Situation)] A ~^heavy{x : Ob ject) A nextTo{r : Ob ject,x : Ob ject,s : Situation) (3)' 
And then we know the world w = {x,s,r,c,z} and W = {x : Object, s : Situation, r : Object, c : 

Ob ject ,z- Ob ject } . 
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Now, let us do typing derivation statement by statement. For (1)', We notice that T-Spt cannot be 
applied since (1)' is of a superset relationship between behavioral terms while T-Spt is for regular terms. 
Thus, we turn to prove that the type of the left hand side of "D" is the same as that of the right hand side. 

For typesetting simplicity, we omit "Wh", return types and the final step of T-Var, and abbrevi- 
ate "Object", "Situation" and "Action" to "Obj", "Stn" and "Atn", respectively, in the following typing 
derivation. 

Left hand side of "D" in (1)': 

fragile : Obi — ^ Stn — > Stn, x : Obi, s : Stn m „ _ 

- — ^ T-RelFlt 

fragile (x, s) 

Right hand side of "D" in (1)': 

drop : Ob j — > Atn, r : Ob j, x : Ob j, s : Stn, broken : Ob i — > Stn — > Stn 

T-FunFlt 
T-DO 
T-RelFlt 

broken(x : Obj, do(drop(r : Obj,x : Obj), s : Stn)) 

According to this typing derivation, we know that both types of the left hand side and right hand side 
are the same one: Situation. So this situation calculus statement is proved to be well-typed. 
For (2)', we have the similar form of typing derivation: 
Left hand side of "=" in (2)': 

paint : Obj — > Atn, x: Obj,c : Obj, s : Stn, color : Obj — > Stn — > Stn^ p UN p LT 
paint (x : Ob j, c : Obj), s : Stn, color : Obj — > Stn — > Stn 



drop{r : 


Obj,x: 


Obj), s : Stn, broken : Obj — > Stn — > Stn 


do(drop(r 


: Obj,x 


: Obj), s : Stn) , broken :Obj^- Stn — > Stn 



do (paint (x : Obj,c : Obj), s : Stn), color : Obj — > Stn — > Stn 

T-RelFlt 

color (x : Obj, do(paint(x : Obj,c : Obj), s : Stn)) 

Right hand side of "=" in (2)': 
c: Object 

According to this typing derivation, we find that the type of the left hand side is Situation, while 
the right hand side has a type: Object, which obviously leads to a mismatch. So this situation calculus 
statement is proved to be not well-typed. In fact, whatever type of c will bring about stuck terms or 
mismatches. Anyway, it can still be fixed. A possible correction is to change the right hand side to 
inColor(c: Object, s: Situation), i.e., to replace c with a corresponding relational fluent to match the type 
of the left hand side. 

Let us check the final sample statement similarly as we did previously: 

Left hand side of "D" in (3)': 

pickup : Obj — > Ob j — > Atn, r : Obj, x: Ob j, s : Stn ^ p UN p LT 
pickupir : Obj, x: Obj), s : Stn 

— T-Poss 



poss(pickup(r : Obj, x : Obj), s : Stn) 

When coming to the right hand side of "D" in (3)', we notice that T-CONJ cannot be applied since 
the right hand side of (3)' is of a conjunctive relationship between behavioral terms while T-CONJ is for 
regular terms. Thus, we turn to check whether types of each part of the conjunction are the same. If so, 
the final type should be Unit according to its definition. 

holding : Obj — > Ob j — > Stn — > Stn, r: Obj, z: Ob j, s : Stn j^ EL p LT 

holdingir : Ob i, z: Obi, s : Stn) 

— t T-NEG 

\/^holding(r : Obj, z : Obj, s : Stn) 

T-Unv1 

(Vz : Obj)-<holding(r : Obj, z : Obj, s : Stn) 
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So we find that (\/z)^holding(r : Object, z : Object, s : Situation) has a type Situation. Similarly, we 
can derive -<heavy(x : Object) to be of type Action by taking two typing derivation steps and nextTo(r : 
Object,x : Object,s : Situation) to be of type Situation by taking one step. By definition, the type of 
the right hand side of "D" in (3)' is not Unit since not all the subterms of the conjunction have the same 
type. Therefore, we can claim that (3)' is not well-typed as well. This time we can fix it intuitively by 
simply changing the functional fluent -heavy {x : Object) into a relational fluent -heavy (x : Object,s : 
Situation). 



5.3 Implementation in OCaml 

In the last section, types of every term and behavioral term written in a modified lightweight situation 
calculus with our type system are checked for consistency theoretically. Now we plan to implement a 
type checker in OCaml which does the same job as we do manually, that is, all the type checking work 
would be fulfilled by a type checker semi-automatically and efficiently, which can give a great hand for 
those who are doing tedious type checking alone. 

One piece of sample code in OCaml which typechecks situation calculus statement (1)' as described 
in 5.2 is shown below: 



(* Types Definition *) 

# type unit = Unit of unit ; ; 

# type bool = Bool of bool;; 

# type stn = Situation; ; 

# type atn = Action; ; 

# type obj = Object;; 



(* T-RelFlt *) 
# let r t s = 

match t with 

Object -> match s with 

Situation -> Situation; ; 



(* T-FunFlt *) 

# let f tl t2 = 

match tl with 

Object -> match t2 with 

Object -> Action; ; 

(* T-Do *) 

# let does bt s = 

match bt with 

Action -> match s with 

Situation -> Situation; ; 



(* Left Hand Side *) 
# let x = Object 
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and s = Situation 

and fragile = r; ; 
val x : obj = Object 
val s : stn = Situation 
val fragile : obj -> stn -> stn = <fun> 

# fragile (x:obj) (s:stn);; 

- : stn = Situation 

(* Right Hand Side *) 

# let b = Object 
and drop = f 
and broken = r; ; 

val b : obj = Object 

val drop : obj -> obj -> atn = <fun> 

val broken : obj -> stn -> stn = <fun> 

# broken (x:obj) (does (drop (b:obj) (x:obj)) (s:stn));; 

- : stn = Situation 

(* This statement is proved to be well-typed *) 

In the OCaml code above, we firstly defined the types in our type system, and then implemented the 
T-RelFlt, T-FunFlt and T-Do typing rules. Finally some necessary variables, two relational fluents 
fragile and broken, and a funtional fluent drop are declared. As a type checking process, these fluents 
fragile, broken and drop are invoked with inputs of pre-defined variables to show the typing relationship 
among them, and the final types calculated for the left hand side and right hand side indicate whether this 
statement is well-typed. 

In this way, all statements that we typechecked manually just now can be dumped into this type 
checker for semi-automatical type checking. Due to some limitation of typing rules in our system, we 
do need some additional manual work occasionally. For instance, we need to check by ourselves that 
whether the types of the left hand side and right hand side of a symbol "D" are the same. Anyway, the 
type checker indeed facilitate our process of deciding whether a situation calculus program is well-typed 
or not. 

6 Conclusions 

Type systems have been proposed to guarantee the soundness of program types by rigid typing mech- 
anisms. As a popular formal language widely used in Artificial Intelligence related fields, situation 
calculus itself has insufficient methods to support a complete and robust type system, with a rudimentary 
typing mechanism: only typed quantifiers for variables. It is obviously not enough for type checking 
the current situation calculus programs. By virtue of our newly-introduced type system for a lightweight 
situation calculus which keep the core of the current one, we can easily do basic type checking for exist- 
ing situation calculus programs which are referred a lot in various study of situation calculus. We also 
implemented the theoretical type system in OCaml as a type checker to substantiate our ideas. With the 
help of this type checker, precedent manual type checking work can be greatly automated for a better 
performance. As for the programs checked out to be ill-typed, we provide corresponding ways for cor- 
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recting them into well-typed forms. 
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